4.4 Objekteigenschaften 

Das wesentlichste Element eines Objekts sind seine Eigenschaften. Eigenschaften beschreiben den Zustand eines Objekts, sind also das individuelle Charakteristikum, um ein Objekt von einem anderen Objekt desselben Typs zu unterscheiden.

Betrachten wir zunächst den einfachsten Fall der Eigenschaftsimplementierung am Beispiel der weiter oben beschriebenen Klasse Circle. Ein Kreis wird bekanntlich zumindest durch seinen Radius beschrieben. Außerdem sollte die Lage des Kreismittelpunktes bekannt sein, um ein Kreisobjekt positionieren zu können. Daher werden in der Klassendefinition neben dem Radius zwei weitere Variablen festgelegt, die sowohl die x- als auch die y-Koordinaten beschreiben.

Eine auf ein Objekt der Klasse Circle zugreifende Methode kann die Eigenschaften direkt manipulieren bzw. die Inhalte auswerten, da diese Public deklariert sind, z.  B.:

Zu den Schlüsselkonzepten der objektorientierten Programmierung zählt die Datenkapselung: Demnach sollten Objektdaten immer vor dem direkten Zugriff durch einen Aufrufer geschützt werden. Die Implementierung der Eigenschaften Radius, XKoordinate und YKoordinate entspricht nicht diesem Paradigma.

Denkt man des Weiteren über den Sinn einer Eigenschaft nach, wird man sehr schnell zu der Erkenntnis gelangen, dass in einer Klasse öffentlich deklarierte Variablen nicht mehr darstellen als die Platzhalter bestimmter Typen. Von einer Objekteigenschaft wird aber deutlich mehr erwartet. Was würden Sie erwarten, wenn in der Klasse Circle noch eine Eigenschaft Farbe definiert wäre, beispielsweise

und Sie einem konkreten Objekt mit

den Farbwert Rot mitteilen? Selbstverständlich würden Sie davon ausgehen, dass das Circle-Objekt auch in dieser Farbe dargestellt wird. Aber die Fähigkeit, den Kreis rot zu zeichnen und nicht blau, lila oder schwarz, hat die öffentlich deklarierte Variable nicht.

Auch die Übergabe an Radius ist nicht unproblematisch. Was ist, wenn der Aufrufer dem Radius eine negative Zahl übergibt? Sicherlich wird ein pfiffiger Mathematiker oder Physiker einen akademischen Erklärungsversuch starten wollen, an dem wir uns aber hier sicherlich nicht beteiligen wollen. Also was ist zu tun, um die Bedingung

zu erfüllen? Denkansätze zur Lösung gibt es mehrere:

Weil wir in den Ausführungen oben festgestellt haben, dass die Definition eines öffentlichen Feldes nicht akzeptabel ist, muss dazu eine Methode herangezogen werden. VB 2005 bietet zu diesem Zweck Eigenschaftsmethoden, auch kurz als Eigenschaften bezeichnet, an. Sehen wir uns dazu zunächst die Syntax an:

Die Angabe des Typs der Eigenschaft ist nur dann zwingend erforderlich, wenn Option Strict auf On festgelegt ist.

Widmen wir uns zunächst den Zugriffsmodifizierern.

Die Angabe eines Zugriffsmodifizierers ist optional. Wird darauf verzichtet, gilt die Eigenschaftsmethode als Public.

Eigenschaftsmethoden koordinieren den schreibenden und lesenden Zugriff auf ein Feld. Der Datentyp der Eigenschaft, den die Eigenschaftsmethode verkörpert, wird am Ende mit As <Datentyp> angegeben. Seltener wird bei einer Eigenschaftsmethode eine Parameterliste von Interesse sein. Sie dient dazu, um den Zugriff auf eine Eigenschaft in Abhängigkeit von Randbedingungen zu steuern. Wir werden das Thema am Ende dieses Abschnitts aufgreifen.

Da auf eine Eigenschaft sowohl lesend als auch schreibend zugegriffen werden kann, enthalten Eigenschaftsmethoden ein internes Prozedurpaar: Get/End Get und Set/End Set. Wird einer Eigenschaft ein Wert zugewiesen, wird der Set-Accessor aufgerufen, soll eine Eigenschaft ausgewertet werden, kommt es zum Aufruf von Get. Falls es sich als notwendig erweisen sollte, kann der Programmablauf zu jedem Zeitpunkt mit Exit Property die Eigenschaft außerplanmäßig verlassen.

Der Wert, den eine Eigenschaft repräsentiert, muss im Objekt gespeichert werden. Die Deklaration einer lokalen Variablen kommt nicht in Frage, weil nach dem Verlassen der Eigenschaftsmethode der Inhalt wieder verloren gehen würde. Um diese Schwierigkeit zu meistern, wird der dem Set-Accessor übergebene Wert in einem Private deklarierten Feld, also auf Klassenebene gespeichert.

Dieser Lösungsansatz bietet zwei entscheidende Vorteile:

Schauen wir uns nun im Detail an, wie einer Eigenschaft ein Wert zugewiesen wird. Mit

wird in der Eigenschaftsmethode der Set-Accsessor aufgerufen und der Wert im Parameter Value des Set-Zweigs übergeben. Im einfachsten Fall wird der Inhalt des Parameters dem Feld dblRadius direkt zugewiesen, das nun Private deklariert ist. Nur Code, der sich innerhalb der Klassendefinition befindet, hat Zugriff auf diese Variable, während der Zugriff von außen nicht möglich ist.

Die Rückgabe des Eigenschaftswertes, beispielsweise mit

erfolgt durch Aufruf von Get, dessen Code im einfachsten Fall wie folgt lautet:

4.4.1 Ergänzung der Klasse »Circle« 

Fassen wir nun alle Überlegungen in Form von Änderungen in der Klasse Circle zusammen. Dabei soll die Übergabe eines unzulässigen Werts an die Eigenschaft Radius verhindert und der Anwender an der Konsole darüber informiert werden.

Die drei Eigenschaften der Circle-Klasse XKoordinate, YKoordinate und Radius werden nun allesamt durch Eigenschaftsmethoden beschrieben. Da sie Public deklariert sind, können sie von außerhalb der Klasse aufgerufen werden. Die Bezeichner der ursprünglich gleichnamigen Felder sind geändert worden, um innerhalb der Klasse die namentliche Eindeutigkeit zu gewährleisten.

Da die Mittelspunktskoordinaten keinen besonderen Anforderungen unterliegen, ist es im vorliegenden Fall vollkommen ausreichend, ohne eine Implementierung des zu übergebenden Wertes direkt an das Feld weiterzureichen bzw. dieses auszuwerten.

Der Ersatz der öffentlichen Felder durch eine Kombination von privaten Feldern und öffentlichen Eigenschaftsmethoden kann sich zu einem späteren Zeitpunkt als großer Vorteil herausstellen. Wenn sich die Implementierung des Programmcodes innerhalb der Eigenschaftsmethode als fehlerhaft erweist oder möglicherweise geändert werden muss, wird der aufrufende Code die Änderung nicht bemerken. Er erkennt nur den für ihn sichtbaren, öffentlichen Teil der Schnittstelle, bestehend aus Bezeichner, Parameterliste und Datentyp. Die Implementierungsänderung bleibt ihm verborgen.

4.4.2 Lese- und schreibgeschützte Eigenschaften 

Es kommt häufig vor, dass eine Eigenschaft entweder schreib- oder lesegeschützt implementiert werden muss. Die Realisierung ist denkbar einfach. Einer schreibgeschützten Eigenschaft wird in der Definition das Schlüsselwort ReadOnly hinzugefügt. Eine so definierte Eigenschaft kann nur über Get aufgerufen werden. Daher ist die Unterprozedur Set zum Setzen einer Instanzvariablen wertlos und darf auch nicht im Prozedurkörper codiert werden.

Eine mit ReadOnly gekennzeichnete, schreibgeschützte Eigenschaft macht natürlich keinen Sinn, wenn es keinen anderen Weg geben würde, ihr einen Wert zuzuweisen. Dieser Weg führt in der Regel über den Aufruf einer anderen Methode der Klasse, die ihrerseits den Wert nach einem vorgegebenen Algorithmus setzt. Oftmals werden gekapselte Felder von schreibgeschützten Eigenschaften auch bei der Initialisierung des Objekts in einem parametrisierten Konstruktor festgelegt.

Soll eine Objekteigenschaft zur Laufzeit einer Anwendung lesegeschützt sein, wird in der Definition der Eigenschaft das Schlüsselwort WriteOnly angegeben. Eine lesegeschützte Eigenschaft darf nur den Set-Accessor enthalten.

Da die Rückgabe einer lesegeschützten Eigenschaft vorgesehen ist, bleibt der Inhalt des privaten Feldes dem Aufrufer verborgen. Die Eingabe eines Passwortes, das dazu benutzt wird, benutzerabhängige Zugriffe auf das Objekt methodenabhängig zu steuern, ist dafür ein typisches Beispiel.

Der Wert einer lesegeschützten Eigenschaft kann selbstverständlich durch eine andere Instanzmethode zurückgegeben werden.

Sichtbarkeit der Accessoren »Get« und »Set«

Wird keine andere Angabe gemacht, entspricht die Sichtbarkeit der beiden Accessoren Get und Set per Vorgabe der Sichtbarkeit der Eigenschaftsmethode. Ist die Eigenschaftsmethode beispielsweise Public, sind Get und Set automatisch ebenfalls ohne Einschränkung sichtbar. Mit einem neuen Feature wartet VB 2005 auf: Die Accessoren dürfen eine individuelle Sichtbarkeit aufweisen. Damit lässt sich der Zugriff auf die beiden Accessoren feiner steuern.

In diesem Codefragment ist die Eigenschaft TestProperty öffentlich definiert. Der Set-Accessor hat keinen abweichenden Zugriffsmodifizierer, folglich kann aus jeder anderen Anwendung heraus der Wert gesetzt werden. Im Gegensatz dazu schränkt der Zugriffsmodifizierer Friend das Auswerten der Eigenschaft auf die aktuelle Anwendung ein. Code, der sich nicht in der gleichen Anwendung befindet, kann den Inhalt des Feldes someValue nicht auswerten.

Der Einsatz der Zugriffsmodifizierer auf die beiden Accessoren unterliegt Regeln, die Sie sich merken sollten:

In der Eigenschaftsmethode müssen beide Accessoren definiert sein.

Nur bei einem der beiden Accessoren darf ein vom Zugriffsmodifizierer der Eigenschaftsmethode abweichender Zugriffsmodifizierer angegeben werden.

Der Zugriffsmodifizierer des Accessors muss einschränkender sein als der der Eigenschaftsmethode. Angenommen die Eigenschaftsmethode ist Public definiert, so können die Modifizierer Friend, Protected und Private benutzt werden. Public wäre in diesem Fall sogar unzulässig.

4.4.3 Die Parameterliste einer Property-Prozedur 

Stellen Sie sich vor, Sie hätten die Klasse Car mit der Eigenschaft Farbe als Komponente einer größeren Anwendung definiert, die von einem Autohändler einer bestimmten Marke eingesetzt wird. Wie Ihnen sicherlich bekannt ist, hängt die angebotene Außenfarbe eines Wagens oft von der Ausstattung eines Typs ab. Bestellen Sie die Version GTI, können Sie möglicherweise nur aus der ansonsten reichhaltigeren Farbpalette Schwarz oder Rot wählen, bei der Version SDI darüber hinaus noch Gelb und Silbermetallic.

Wie aber kann diese Abhängigkeit einer Klassendefinition mitgeteilt werden? Müssen Sie für jede Ausstattungsvariante eine neue Klasse implementieren, oder bieten sich andere Möglichkeiten an?

Es gibt andere Möglichkeiten. Sie können die Parameterliste der Eigenschaftsmethode dazu benutzen, die Farbwahl abhängig vom gewählten Typ zu überprüfen. Dazu wird bei der Zuweisung der Farbe an das Car-Objekt als Argument der Typ angegeben.

Es sei davon ausgegangen, dass den Farben Integer-Konstanten zugeordnet sind. Die zu diesem Aufruf zugehörige Definition der Property-Prozedur würde in diesem speziellen Fall wie folgt lauten:

Sie können die Parameterliste auch dazu benutzen, mehrere Zustandswerte mit einem Aufruf dem Objekt mitzuteilen. Bezogen auf das Beispiel wäre es demnach möglich, neben dem Farbwert auch in einem Aufruf die Ausstattungsvariante des gewählten Typs festzulegen.

Ein kleiner Hinweis ist an dieser Stelle angebracht. Der Zusammenhang zwischen der Ausstattungsvariante und den angebotenen Farben ist offensichtlich. Sollten Sie auf eine ähnliche Problematik stoßen, wäre es überlegenswert, die Abhängigkeiten durch eine Datenbank abzubilden. Da das Beispiel nur als eine Demonstration des Einsatzes der Parameterliste dient, haben wir auf eine genaue Analyse zur Findung der besten Lösung verzichtet.

Sie werden wahrscheinlich nur sehr selten eine Eigenschaft mit einer Parameterliste definieren müssen. Sinnvoll ist eine Parameterliste meist nur dann, wenn beim Setzen einer Instanzvariablen Randbedingungen von Interesse sind, die einen Einfluss auf den endgültigen Inhalt des Feldes haben.

4.4.4 Standardeigenschaften 

Eine Standardeigenschaft kann auf eine Objektreferenz aufgerufen werden, ohne die Eigenschaft ausdrücklich anzugeben. Voraussetzung ist, dass in der Parameterliste der Eigenschaftsmethode zumindest ein nichtoptionaler Parameter angegeben ist. Das alleine ist allerdings noch nicht ausreichend, zusätzlich muss der Methodensignatur mit Default noch ein weiterer Modifizierer hinzugefügt werden.

Betrachten Sie das folgende Codefragment einer Standardeigenschaft, die diese beiden Bedingungen erfüllt:

Die Eigenschaft MyProp kann nun auf zweierlei Weise aufgerufen werden. Zunächst einmal bietet sich der herkömmliche Weg über die explizite Angabe des Eigenschaftsnamens an, also:

Wegen der Inanspruchnahme der Standardeigenschaft wäre die kürzere, aber sicherlich auch schlechter lesbare und daher auch weniger empfehlenswerte Variante:

Was auffällt, ist die syntaktische Ähnlichkeit mit der Zuweisung an ein Array-Element, was durchaus zu Verwechslungen führen kann. Interessant wird es aber insbesondere dann, wenn tatsächlich ein Objekt-Array dieses Typs deklariert und der Standardeigenschaft eines Elements dieses Arrays ein Wert zugewiesen wird.

Zunächst wird das dynamische Objektfeld obj mit vier Elementen deklariert. Jedes Element eines Objekt-Arrays muss einzeln initialisiert werden – im Beispiel oben ist es das zweite Element mit dem Index 1, dessen Standardeigenschaft in der darauf folgenden Codezeile ohne explizite Angabe des Feldnamens MyProp ein Wert zugewiesen wird.

Es lässt sich kaum darüber streiten, ob die Zuweisung in die Kategorie gute Lesbarkeit fällt oder nicht. Welcher der beiden Klammerwerte repräsentiert den Array-Index des Elements, welcher ist das der Parameterliste übergebene Argument? Besser wäre es, die Eigenschaft explizit zu nennen:

Sie sollten sich daher sehr genau überlegen, ob Sie eine Eigenschaft zu einer Standardeigenschaft erklären.

4.4.5 Das With ... End With-Statement 

Sie werden sehr oft in die Situation kommen, auf die Eigenschaften oder Methoden eines Objekts mehrfach hintereinander zugreifen zu müssen. Es kann dabei recht mühevoll werden, immer wieder den Bezeichner neu eingeben zu müssen.

Visual Basic bietet mit dem With ... End With-Statement eine recht attraktive Möglichkeit, sowohl die Tipparbeit zu verkürzen als auch den Programmcode übersichtlicher zu gestalten. Die Syntax hierzu lautet:

Schauen wir uns den Einsatz an einem kleinen Beispiel an, bei dem wir wieder die Existenz einer Klasse Car annehmen:

Es werden mehrere Statements auf ein Objekt ausgeführt, ohne die qualifizierende Referenz anzugeben. Die Punktnotation wird vor dem Punkt aufgebrochen, der nun vor der Angabe einer Elementfunktion geschrieben werden muss, um die Zugehörigkeit der Elementfunktion kenntlich zu machen. Dabei spielt es keine Rolle, ob es sich bei der Elementfunktion um eine Eigenschaft oder Methode handelt.

With ... End With-Statements können auch verschachtelt werden. Dieser Fall setzt eine zumindest zweifach auftretende Punktnotation voraus, die dann auftritt, wenn eine Objekteigenschaft ihrerseits selbst wieder durch ein anderes Objekt beschrieben wird.

Eine diametrale Verschachtelung ist nicht zulässig.

Das With ... End With-Statement unterliegt einer Einschränkung: Es darf nur auf Objekte angewandt werden.

4.4.6 Konstanten mit »Const« und »ReadOnly« 

Sie könnten die öffentliche Variable einer Klasse mit ReadOnly schreibgeschützt implementieren:

Ein zweite Alternative bietet das Schlüsselwort Const.

Was im ersten Moment identisch aussieht, birgt dennoch einen kleinen Unterschied. Der Wert einer als Const definierten Konstanten kann zu keinem Zeitpunkt der Laufzeit verändert werden.

Etwas weniger restriktiv verhalten sich ReadOnly-Konstanten, denn deren Wert kann tatsächlich noch geändert werden. Allerdings beschränkt sich der Zeitpunkt der möglichen Änderung auf die Ausführung eines Konstruktors, der bei jeder Objektinstanziierung aufgerufen wird (Konstruktoren behandeln wir weiter unter in diesem Kapitel).

Wenn das Objekt vollständig erstellt ist, ist eine Änderung der ReadOnly-Konstanten nicht mehr erlaubt.

4.4.7 Der Zugriff auf private Daten 

Eine Objektmethode kann nicht auf die privaten Daten eines anderen Objekts zugreifen. Dies war bisher immer die Aussage, die allerdings nicht uneingeschränkt gültig ist, wie das folgende Beispiel der Klasse TestClass zeigen soll.

In der Klassendefinition ist das Feld intVar Private deklariert, um den unbefugten, direkten Zugriff von außen zu unterbinden. Dieses Feld kann infolgedessen nur durch eine Eigenschaft manipuliert werden, in unserem Beispiel MyValue.

Mit etwas Besonderem wartet die Methode InternProc auf. Sie empfängt beim Aufruf im Parameter obj die Referenz auf ein anderes Objekt vom Typ TestClass. Es mag überraschend klingen, aber diese Referenz soll dazu benutzt werden, um auf die private Instanzvariable intVar des übergebenen Objekts zuzugreifen. Nach allen bisherigen Aussagen dürfte dieser Zugriff eigentlich nicht erlaubt sein.

Im folgenden Codefragment wollen wir die Klasse TestClass testen. Dazu werden zwei konkrete Objekte vom Typ TestClass erzeugt und der Eigenschaft MyValue des ersteren ein Wert zugewiesen.

Im nächsten Schritt folgt der Aufruf der InternProc-Methode des Objekts obj2 unter Übergabe der Referenz auf das Objekt obj1.

Tatsächlich wird an der Konsole der Inhalt der gekapselten, privaten Instanzvariablen angezeigt:

Die Kapselung der Variablen wird also aufgebrochen, die Variable ist auswertbar. Dieser Effekt scheint im Widerspruch zu dem zu stehen, was Sie bisher über die Kapselung gehört haben, und bildet die einzige Ausnahme, die der folgende Satz beschreibt:

4.4.8 Zusammenfassung 

Zustandsdaten eines Objekts werden in Feldern vorgehalten. Ist ein Feld Public deklariert, gehört es zur öffentlichen Schnittstelle eines Objekts und kann ohne Einschränkungen von außen manipuliert werden.

Ein Private deklariertes Feld kapselt den von ihm beschriebenen Wert. Der Wert kann nur von Code, der sich innerhalb der Klasse befindet, manipuliert werden.

Standardmäßig enthält eine Eigenschaftsmethode die beiden Accessoren Get und Set, die jeweils einen eigenen Anweisungsblock beschreiben. Der Get-Block wird ausgeführt, wenn ein externer Aufrufer ein bestimmtes Feld auswerten möchte, der Set-Block wird bei der Zuweisung an ein Feld aufgerufen.

Fehlt in einer Eigenschaft der Set-Accessor, handelt es sich um eine schreibgeschützte Eigenschaft, fehlt der Get-Accessor, ist die Eigenschaft lesegeschützt. Eine schreibgeschützte Methode wird um den Modifizierer ReadOnly ergänzt, eine lesegeschützte um WriteOnly.

Einer der beiden Accessoren kann eine von der Eigenschaftsmethode abweichende Sichtbarkeit haben. Dazu wird dem Accessor ein Zugriffsmodifizierer vorangestellt, der einschränkender sein muss als der der Eigenschaftsmethode.

Konstanten werden im Deklarationsabschnitt einer Klasse festgelegt. Sie ähneln einer Felddefinition, ergänzt um das Schlüsselwort Const und den von ihnen repräsentierten Wert.

Eine Konstante kann auch mit dem Schlüsselwort ReadOnly definiert werden. Die Zuweisung an ein ReadOnly-Feld muss nicht in der Deklarationsanweisung stehen, sondern kann auch in einem Konstruktor erfolgen.

Aus einem Objekt heraus kann auf private Instanzvariablen eines anderen Objekts zugegriffen werden – vorausgesetzt, beide Objekte sind vom gleichen Typ.